Management 3.0 - Improve everything
まとめ
環境はシステムの影響を受ける (新しいものを導入すると環境が変化しうる)
人は変化に対して抵抗しやすい
継続的改善へのアプローチは、適応、探索、予測の 3 つ
変更が難しいのは、アトラクタに捕らわれているからかもしれない
環境を変えることで、アトラクタを変えることもできる
適応度地形を適応歩行しやすくするため、プロジェクト内の要素の相互作用は小さくしておくとよい 非線形システムを改善していく際、場合によっては一時的に悪くなることもある
段階的な変更で少しずつ登るのと、根本的な変更でジャンプするのを組み合わせていく
変化を推進するためにマネジャーができること
適応度地形で適応していくために、環境を変える (そして適応度地形を変える) メンバーが変化を望ましいものとみなすようにする (停滞を苦痛にする)
パフォーマンス向上の戦略
自分たちの何かを変えて探索してみる
以前のトップパフォーマーたちのベストプラクティスを混合してシステムを作る
他のシステムからベストプラクティスを学ぶ
いずれにせよ、継続的に変化していく必要がある
Chapter 14 : The Landscape of Change
システムを環境に導入すると、環境は変化する
nobuoka.icon 観察者効果と似たような話だ なので、現在の環境を基に新しいものの導入を計画するのは困難 (導入したら環境が変わるので)
確実性を達成しようとすると、意思決定できなくなりうる
人は、意思決定の際に、機会を求めるよりリスク回避したがる
nobuoka.icon 正の結果より負の結果の方を過大に評価する、みたいなやつだ
成功したソフトウェアは、多くのメンテナンスが必要
2 つの理由
人々は予期せぬ使い方をしたりする
成功したら長く使われるので、ハードウェアやソフトウェアの要件が当初より変わってくる
要は、変更しなければ徐々にユーザーを満足させる能力が低下する (そして複雑さは (明示的に減らさないと) 増えていく) ということ
適応させるために変更する労力は、ソフトウェアの生涯を通して一定
成功とは、失敗するまでのこと
適応度は、その種自体の特性ではなく、環境にいかに適合するかで決まる
製品の適応度も同様に、その製品が意図したとおりに動く能力で決まるのではなく、特定のコンテキストで利害関係者にもたらす価値によって決まる
変化を受け入れるには？
プロセスに焦点を当てるのは、変化に対応するにあたって狭すぎる
プロセスだけでなく、システム全体の考慮が必要
11 章で説明したソフトウェアプロジェクトの 7 つの側面 (機能、品質、ツール、人、スケジュール、プロセス、およびビジネス価値) が改善の候補になるはず
アジャイル手法における学習
ソフトウェアでも、ユーザー満足度を維持するためには改善し続けなければいけない
狩野モデルにも反映されており、魅力的な機能もやがては標準的な機能とみなされるようになる いろいろな尺度が提案されているが、標準的なものはない
定義できなくても見ればわかる
nobuoka.icon WTFs/m もこれに近い考えっぽい 取りえる状態は大量であっても、安定した状態は少ない
ソフトウェアプロジェクトについても、その環境でうまく機能するものが安定していることを確認する必要
安定しているからといってうまく機能するとは限らない
安定している状態から別の状態に移そうとしても、なかなか難しい
少し変数を変えたぐらいでは、同じアトラクタに収まってしまう
良い状態で安定しているなら良いが、悪い状態から抜けられないということも多い
アトラクタは環境によって変わるので、環境を変えるという発想が必要
例 : TDD を導入しようとしても、チーム内の努力では無理だった → 別の環境では簡単にできた ソフトウェアプロジェクトでは、機能、品質、人、ツール、スケジュール、プロセスを繰り返し変更することで、適応歩行を実行 適応度地形はシステムと環境によって異なるので、あるシステムでうまくいった変更が他のシステムでうまくいくとは限らない システムは、環境やシステム同士で適応する
環境の変化とシステムの共進化により、適応度地形は変化していく → 戦略を何度も評価しなおす必要がある
複雑系では、システム内部の要素同士の相互作用があるため、適応度地形は小さなピークが多数ある形 要素同士の相互作用の大きさが影響するので、相互作用が小さいほど適応度地形で適応歩行しやすい
ソフトウェアプロジェクトの機能、品質、人、ツール、プロセスの間の相互依存関係を中程度にすること
チームは基本的には有向適応を行うが、無意識的な変化 (無向適応) も起こす
Chapter 15 : How to Improve Everything
世の中の改善モデルを統合して、SLIP という改善モデルを著者が開発 多くの改善モデルは、線形の改善を想定している = 局所最適になってしまう問題を避けられない
段階的な改善ではなく、急激なジャンプを数回行うことが賢明な場合もある
リーンソフトウェア開発の文献では、カイゼン (段階的改善 (gradual improvement)) を説くものはあっても、カイカク (根本的改善 (radical improvement)) を説くものはごくわずか 改善するにはまず現在地を知ること
マネジャーは、自身の目で問題を確認する必要がある
把握しておくべきこと
谷にいるとより良い状態が見えない
山への移動に時間がかかるほど、山が消える可能性がある
最良の山がどこかを直接見ることはできないが、大体どの範囲にあるかは把握すること
どれか一つの山に登って初めて、他の山がより高いかどうかがわかる
具体的には？ (ひどい状況にあるという想定で)
まずは小さな改善 (より良い規律やコーディングガイドラインなど) を行っていく
作業方法を、いくつかの段階を経て大きく変える (スクラムや XP、カンバンの導入など)
最初からうまくいくとは限らないが、振り返りなどの段階的改善で徐々に良くなるはず
うまくいったら、そこからさらにジャンプすることも検討
マネジャーには、チームのパフォーマンスを向上させるために環境を変える力がある
組織構造も環境の重要な側面
変化に対する意欲が最も重要
組織の変化を定常的なものにする (ジョブローテーションとか)
組織の変化に名前を付けたりはしない (そうすると、組織変更が特別なものというメッセージになってしまう)
人々は、変化を望ましいものだと思った時に、変化する
変化を望ましいものに紐づけると良い
組織内の人のネットワークから広げていくという手も
ハブやパルステイカー、コネクタ、セールスマンらと協力するとか
価値は主観的なので、変化に対して感じる価値も人によって違う
変革に置く価値は、ビジネス価値とは相関せず、それをしなかった時の痛みの大きさに比例する
痛みを感じた経験があると、痛みを防ぐための変化に大きな価値を感じる
苦痛を与えて変化したいと思わせる作戦
過ちがあっても、そこから学ぶことがある
過ちは回避すべきものではなく、学習機構としてみるべき
間違いを犯さないようにしようとするとほとんど学ばない
環境によって引き起こされるエラーとノイズが、システムをかき混ぜて、最適ではない状態から抜け出させる
ソフトウェア開発においても、低い完全性と実行時のノイズにより、同様のことを起こせる
実証済みのベストプラクティスを再結合させる自然な方法
nobuoka.icon ソフトウェア開発チームにおいては、交叉も遺伝子の水平伝播も同じな気がする？ (チームは個体ではないので、2 つの間の差異はない気がする) 交叉ががっつり 2 つのシステムを組み合わせるのに対して、遺伝子の水平伝播は一部のみ取り込む、って感じかな 最近の調査では、アイデアのコピーが最も成功している戦略
コピーのために、他の観察 (他からの学習) に多くの時間を費やす必要がある
コピペの改善 (copy-paste improvement) をしないように
他システムからの取り込みをするにあたって、自分たちの状況に適しているかどうか判断する必要がある
実用的なヒント
組織の様々な階層で実施可能
明示的な多段階の改善モデルを使用する (SLIP やその他のもの) 改善バックログの項目を、これらのステップを列に持つカンバンで管理すると便利 プロジェクトをまたぐトピックについての独自のコミュニティを作ることを組織メンバーに提案
自己組織化のことを考えると、マネジャー自身が作るのは避けた方がよい
アジャイルであることは、生存についてである
安定した環境ではシステムはしばらく安定だが、変化を忘れてしまってはやがて環境変化に追随できなくなる
変化を理解し、変化を受け入れ、変化し続ける必要がある